The present invention pertains to the list industry, and more particularly to the automation of transaction processing among list brokers, list managers, and service bureaus.
The list industry is built up around the selling and buying of information in the form of lists; the lists themselves are typically not sold, but only rented, i.e. copies of the lists are rented. As shown in FIG. 1, a transaction related to the buying or selling of information in the form of lists can involve different entities, forming what is known as a supply chain, including clients acting as mailers, list brokers, list managers, service bureaus, and list owners.
List owners own the list properties that are placed into the market for rent. Mailers are the renters of list properties and in almost all cases are list owners themselves. List brokers take orders from their clients and introduce orders into the supply chain. List managers manage a list for a list owner, receive orders from list brokers and submit orders for fulfillment to service bureaus. Service bureaus store the actual list data, receive and execute orders from list managers, and deliver the deliverable to the list broker's client, bonded mail house or other point-of-use. List marketers compile and publish extensive and comprehensive catalogs of lists commonly called datacards. Datacards are also compiled internally by list brokers. Datacards specify the general characteristics of a list, including its content, permissible (but not all) select filters used to obtain subsets of the content, miscellaneous ordering options, and for each orderable item, the unit of purchase and rate. List brokers use datacards from list marketers to determine the lists and the select filters that might best satisfy a client's requirements.
A list is a list of names having associated properties and manner of delivery and use. Usually only a subset (or multiple subsets) of a list is needed. The subset is selected from the whole list using one or more filters to filter out all except the desired content by comparing one or more of the properties of the list with select criteria. A filter is therefore commonly referred to as a “select” and the filter's constraint may be specified by a code, a single value or range of values, or a combination thereof. Combinations of constraints can be applied (in which case each is logically “AND'ed” with the others providing a so-called multiple filter), and/or alternative constraints can be applied (in which case each is logically “OR'ed” providing a so-called composite filter). (In addition, corresponding excluding constraints can also be applied, i.e. “AND NOT” and/or “OR NOT.”)
In a typical order for a subset of a list, a mailer (list purchaser) indicates a subset of a list to a broker. The broker then issues an order for the subset using a select filter expressed in ordinary English. A list manager then reviews the order, typically refining it in the process, based on industry knowledge or familiarity with the particular list referred to in the order. The list manager will then send the reviewed list onto a service bureau, which will then fulfill the order. The communication from the broker to the list manager and the communication from the list manager to the service bureau are typically via facsimile, or can be electronic (e.g. an email), but are usually not communications between automated processes. Thus, an order arriving at a service bureau is typically keyed into an automated system at the service bureau after arriving by facsimile from a list manager. This is because the native format for representing an order can differ from facility to facility. Thus, if an automated process is used for specifying a list at one facility in the supply chain, it may not be able to communicate with an automated system at another facility in the supply chain because the other facility might use an automated process that represents a list differently.
As mentioned, a select filter is often today expressed in ordinary English. Using ordinary English to indicate a subset of a list (or lists) often causes ambiguity, and so the mailer (list renter) sometimes does not end up with the desired subset. Further, the keying in of an order when it arrives at a supply chain facility is a source of error, cost and delay.
What is needed therefore is a lingua franca—i.e. a common trade language or lingo—by which automated processes of entities of the supply chain could communicate with each other, even if some ambiguity exists. Ideally, though, a standardized trade language would be provided sufficient in its vocabulary to provide precise expressions for orders of all possible subsets of any list, and so eliminating all ambiguity in orders for subsets of lists.